Subject: Flow control scope

From: [email-masked]
Date: Mon, 12 Jul 93 11:58:11 EDT

The flow control scheme that we've been discussing was intended to      n
operate on a per-circuit basis, not a switch-switch connection basis.
I'm with Paul that this is the right scope for our discussion - it
maps to the LLC RR/RNR mechanism and provides a "least common denomi-
nator" for dealing with the different congestion points in a product;
e.g., adapter-level, box-level.

I've gotten some more background information on the scheme David
originally documented and would like to throw out a couple points:
- The SSP frames ENTERBUSY and EXITBUSY may be needed to prevent
  certain race conditions in circuit establishment, independent of
  normal circuit-up data flow control.  I need to understand this
  and the connect sequences better, but I just wanted to mention
  that even if we decide we don't want them for regular flow control
  they may have another use.
- The scheme was intended to allow DWSI and IWSI on any frame from
  pacing receiver to pacing sender, not just on pacing responses.
  This is similar to the RWI (reset window) algorithm in VR pacing,
  and is one way we could do unsolicited responses.  Another way might
  be a little more APPN-ish and have a new window size explicitly
  expressed by the receiver.

I'm curious to know if people feel this siglet's mission should also
address flow control of a local LAN-to-SDLC circuit.  My current feeling
is that this is just a product implementation issue and we should deal
only with the SSP.

On the direction of this discussion - so far we're discussing possible
ingredients of different schemes and I think that's very necessary.  At
some point we'll have to move to exchanging concrete proposals we feel
are complete.  Is there a target date we need to shoot for in moving to
the proposal mode?

Peter Gayek

---

From: "Bernard Brady" <[email-masked]>
Date: Tue, 13 Jul 93 10:39:14 EDT

>Received: from ibmstandards.cary.ibm.com by BBN.COM id aa12067;
>          12 Jul 93 12:02 EDT
>Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.239.48.4] with SMTP
>	id AA162176 (for [email-masked], from [email-masked]/[email-masked]); Mon, 12 Jul 93 11:54:34 -0400
>Message-Id: <[email-masked]>
>Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 0120;
>   Mon, 12 Jul 93 11:58:44 EDT
>Date: Mon, 12 Jul 93 11:58:11 EDT
>From: [email-masked]
>To: aiw-sig-dlsw-flow [email-masked]
>Subject:  Flow control scope
>

Peter,

If we are looking at things that should be resolved by the RFC then it
is general flow control.  In this regard I think that it should be at
both the connection and circuit level. The circuit level is typically
caused by the associated end node sending an RNR.  At the connection
level  this requires flow control messages for each circuit associated
with a connection.   In the case where there are n circuits then 2n
messages are required for flow off and on.  By allowing the flow control
at both levels it reduces some of this overhead.  

What could n be is a critical point in this discussion. Since NCP has
this interesting feature (bug) that allows only a DSP of 04 and a
SAP of some multiple of 4 this only allows 64 circuits off a single
connection.  Lets also say that  there is a case of  20 connections
coming into a router, all containing 64 established circuits.  If the
router ever wanted to flow control all of the connections this would
take 1280 DLSw RNR messages. Flow control at the connection level would
take 20 messages. 

If the intention was for flow control to only be at the circuit level
then what does the current product do in this case, take the TCP/IP
connection down or flood the network with RNR messages?

Another issue is that circuit level flow control  does not deal with the 
case where people are passing  LLC1(UI frames)  over this DLS
connection. By what I read in the RFC this is a valid case once the
connection is established.  Some people might say that the data will
just be dropped on the floor and it is a implementation feature on how
to deal with this problem.  Because DLS is above TCP/IP the associated
frames are using system resource and CPU cycles in order to propagate
frames which will eventually be dropped on the floor.  

A related issue is what service takes precedence in a  flow control
environment.  At what point will  LLC1 frames be dropped on the floor
versus allowing circuit related data to flow over the connection.  Is
this left to the implementor  or does the current implementation have a
method for allowing LLC2/NetBios  and LLC1 data flow to provide 
comparable service.  

I am still coming up to speed on DLS and if I have mis read the RFC or
possible problems created by flow control only at the circuit level
please respond update this accordingly.

Bernie

---

From: "Bernard Brady" <[email-masked]>
Date: Tue, 13 Jul 93 14:27:13 EDT

Peter,

After re-reading my mail I saw that I incorrectly had swapped the
uses of circuit and connection.  I corrected the mail and am resending it.

Bernie

If we are looking at things that should be resolved by the RFC then it
is general flow control.  In this regard I think that it should be at
both the circuit and connection level. The connection level is typically
caused by the associated end node sending an RNR.  At the circuit
level  this requires flow control messages for each connection associated
with a circuit.   In the case where there are n connections then 2n
messages are required for flow off and on.  By allowing the flow control
at both levels it reduces some of this overhead.  

What could n be is a critical point in this discussion. Since NCP has
this interesting feature (bug) that allows only a DSP of 04 and a
SAP of some multiple of 4 this only allows 64 connections off a single
circuit.  Lets also say that  there is a case of  20 circuits
coming into a router, all containing 64 established connections.  If the
router ever wanted to flow control all of the circuits this would
take 1280 DLSw RNR messages. Flow control at the circuit level would
take 20 messages. 

If the intention was for flow control to only be at the connection level
then what does the current product do in this case, take the 
circuit down or flood the network with RNR messages?

Another issue is that connection level flow control  does not deal with
the case where people are passing  LLC1(UI frames)  over this DLS
circuit. By what I read in the RFC this is a valid case once the
circuit is established.  Some people might say that the data will
just be dropped on the floor and it is a implementation feature on how
to deal with this problem.  Because DLS is above TCP/IP the associated
frames are using system resource and CPU cycles in order to propagate
frames which will eventually be dropped on the floor.  

versus allowing connection related data to flow over the circuit.  Is